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METHOD AND SYSTEM FOR AUTOMATING OCCUPATIONAL HEALTH 
AND SAFETY INFORMATION MANAGEMENT 

BACKGROUND OF THE INVENTION 

5 

1. Field of the Invention 

This invention relates generally to 
occupational health and safety, and more specifically to 
10 a method and system for automating occupational health 
and safety information management. 



Background Art 



15 The Occupational Health and Safety 

Administration ("OSHA" www. osha . gov ) was established in 
1971 to ensure safe and healthful workplaces in America. 
OSHA sets forth and maintains a comprehensive set of 
standards for assuring safe and healthful conditions for 

2 0 working men and women. Since the agency was created in 
1971, workplace fatalities have been cut in half and 
occupational injury and illness rates have declined 40 
percent. At the same time, U.S. employment has doubled 
from 56 million workers at 3.5 million worksites to 111 

25 million workers at 7 million sites today. 

Maintaining compliance with OSHA standards and 
managing health and safety-related information is an 
important and challenging task - especially for larger 
organizations employing hundreds or thousands of 

30 employees nationally. First, there is a tremendous 

amount of information to gather, process, analyze and 
report to establish compliance (e.g. patient medical 
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visits, organizational injury/illness statistics, OSHA- 
required reports, etc.). Second, information originates 
from many different sources throughout an organization. 
This fact challenges centralized management of 
5 occupational health and safety-related information. 

The following table compares disadvantages of 



the conventional methodology for managing occupational 
health and safety-related information against certain 
advantageous aspects of the present invention. 





Aspects of Present Invention 






► No standardized data 


► Easy web-based single 


► Data analysis for decision 


point of entry for 


making is difficult 


information shared across 


► Potential for lost 


the entire business 


paperwork 


► Ability to analyze data 


► Variety of reporting 


for process improvement 


methods 


► Improved ease-of-use and 


► Pen and paper reporting 


functionality 


► Time-consuming 


► No loss of existing 


► Requires supervisor's 


functionality 


direct involvement 


► Standardizes incident 




investigation and reporting 




► Electronic reports are 




immediately available to: 




► Plant 




Managers 




► Safety 




Engineers 




► Supervisors 




► UAW Health & 




Safety Reps. 
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What is needed is a comprehensive system and 
methodology for the efficient administration of 
occupational health and safety information and OSHA 
compliance. Embodiments of the present invention provide 
5 such a solution - leading to a reduction in injury, 
illness and loss through prevention. 

SUMMARY OF THE INVENTION 

10 One embodiment of the present invention is a 

computer- implemented occupational health and safety 
information management ("OHSIM" ) system. 

Embodiments of the present invention enable 
users to manage occupational health and safety 

15 information. Users can input medical data, incident 

investigation data, perform data analysis, and generally 
administer the management of occupational health and 
safety information in an automated fashion. 
Functionality associated with the present invention may 

2 0 be divided into three general modules: an Electronic 

Medical Record ( " EMR " ) module, an Incident Investigation 
module ("IIM" ) # and a Data Analysis module ("DAM"). 

Within a corporate environment, several 
different users will find aspects of the present 
25 invention beneficial. For example, plant operations 

staff, safety engineers and union representatives may use 
aspects of the present invention to access statistical 
information and to analyze /control risk situations 
promoting safety in the workplace. A company's clinical 

3 0 healthcare providers may use aspects of the present 

invention to easily open/edit occupational and personal 
medical visits, update medical history information, 
open/edit medical leaves, and trigger investigations of 



work related injury/illness events. Supervisors, team 
leaders and safety engineers may use aspects of the 
present invention to enter, maintain and process/query 
incident investigation data, including information on 
5 property damage and near miss events. Plant level 

application administrators may use aspects of the present 
invention to adjust security access levels, as well as 
administer data reporting tools. Worker's compensation 
representatives may use aspects of the present invention 

10 to access occupational visit data and personal visit 
information. Human resources representatives may use 
aspects of the present invention to open/edit or create 
medical leaves and administer job placement /no work 
available (NWA) leaves. Corporate and plant operations 

15 staff, superintendents, area managers, plant level 

reporting personnel, and medical staff may use aspects of 
the present invention to query statistical information 
about a particular plant or multiple plants. 

Benefits of the present invention include data- 

2 0 driven company processes which reduce workplace hazards, 
standardized processes, efficient in-plant medical data 
management, a standardized single point of entry for data 
collection, and electronic reports that are available to 
plant managers, safety engineers, supervisors, union 

2 5 representatives, and many others. 

Embodiments of the present invention include 
methodologies, computer systems and computer software for 
automated health and safety information management. 
Depending upon the particular embodiment, aspects of the 

3 0 present invention may include an electronic medical 

record module configured to receive a plurality of data 
concerning patient medical visits resulting from 
occupational health or safety incidents (e.g. injuries, 



illnesses, etc.), process the data based on pre-defined 
OSHA logic to automatically identify one or more patient 
medical visits that are OSHA-recordable , and output one 
or more reports including a summary of the data 
5 characterizing one or more patient medical visits that 
are OSHA-recordable . 

Another aspect of the present invention 
includes an incident investigation module configured to 
electronically dispatch an investigator to investigate 

10 one or more of the occupational health or safety 

incidents, and receive a plurality of data concerning an 
investigation of one or more of the occupational health 
or safety incidents including one or more corrective 
actions to avoid reoccurrence of the one or more of 

15 occupational health or safety incidents. 

Another aspect of the present invention 
includes a data analysis module configured to filter 
received data at one or more filter levels (e.g. worker 
characteristics, injury/illness codes, work assignment, 

20 time period, etc.) based on one or more user-defined 

criteria, and generate a plurality of reports based on 
the filtered data. 

Data characterizing the patient medical visit 
may include data representing the date of the incident, 

25 whether the patient died or lost consciousness, 
diagnosis, treatment, medications, test orders, 
referrals, medical leaves, medical restrictions, an 
indication as to whether the patient is fit for work, 
etc . 

3 0 According to another aspect of the present 

invention, an indication may be automatically displayed 
as to whether enough data characterizing the patient 
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medical visits has been provided to determine whether the 
visit is OSHA-recordable . 

According to another aspect of the present 
invention, functionality is provided enabling users to 
5 query collected data in a variety of different manners to 
produce or otherwise output a plurality of different 
report types. For example, a report summarizing the 
occupational health or safety incidents for a particular 
organizational location or patient, a report summarizing 

10 patient medical leaves of absence for a particular 

organizational location or patient, a report summarizing 
patient medical restrictions for a particular 
organizational location or patient, a report summarizing 
patient medical visits for a particular organizational 

15 location or patient, a report summarizing one or more 

incident investigations, a report summarizing corrective 
actions to avoid reoccurrence of the one or more of 
occupational health or safety incidents, etc. 

2 0 BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 illustrates an overview of the OHSIM 
system in accordance with a preferred embodiment of the 
present invention; 
25 Figure 2 is a block-flow diagram illustrating a 

methodology or flow-of -events associated with the EMR 
module according to one embodiment of the present 
invention; 

Figure 3 is a block-flow diagram illustrating a 

3 0 preferred methodology or flow-of -events for recording an 

occupational medical visit using one embodiment of the 
present invention; 
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Figure 4 is an example graphical user interface 
including a complete/verification status screen in 
accordance with one aspect of the present invention; 

Figure 5 is an example GUI for defining a 
5 diagnosis in accordance with one aspect of the present 
invention; 

Figure 6 is an example GUI for implementing an 
OSHA log analysis in accordance with one aspect of the 
present invention; 
10 Figure 7 is a block-flow diagram illustrating a 

preferred methodology for using and implementing the IIM; 

Figure 8 is an example GUI illustrating a Work 
Queue Search in accordance with one aspect of the present 
invention; 

15 Figure 9 is a multi-tab GUI for collecting a 

plurality of information relating to a new incident 

investigation in accordance with one aspect of the 

present invention; 

Figure 10 illustrates an example view and 
20 investigation screen in accordance with one aspect of the 

present invention; 

Figure 11 graphically illustrates a preferred 

methodology for utilizing the data analysis aspect of the 

present invention ; 
25 Figure 12 is an example GUI having a plurality 

of tabs associated with data selection and output in the 

DAM; 

Figure 13 is an example DAM form 88 for 
specifying the format of the data to be output; 
30 Figure 14 is an example chart output in 

connection with the DAM aspect of the present invention; 
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Figure 15 is an example DAM GUI for specifying 
detail selections associated with statistical reporting 
in the DAM aspect of the present invention; and 

Figure 16 is an example detail selection screen 
5 for organizational variables in accordance with the DAM 
aspect of the present invention. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT ( S ) 

10 One embodiment of the present invention is a 

computer- implemented occupational health and safety 
information management system ("OHSIM"). Aspects of the 
present invention may be divided into three general 
modules: the Electronic Medical Record ( " EMR " ) module, 

15 the Incident Investigation module ("IIM" ) , and the Data 

Analysis module ("DAM"). As will be discussed in greater 
detail below, each of the modules may be implemented in 
computer software and hardware and may be configured to 
share information in an electronic fashion with one 

2 0 another. 

Roles and tasks of system users can vary widely 
depending on the particular implementation of the present 
invention. In accordance with a preferred embodiment of 
the present invention, however, Table 1 below illustrates 
25 a preferred matrix of user roles and responsibilities. 



Table 1 
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Super- 
intendents 
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HR/ 
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X 
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T 1 lnpc;c; 
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X 
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±111 L 1Q LC 
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X 
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X 








View 

Investigation 
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Complete 
Investigation 
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X 








Review Near 
Miss Reports 




X 










rvc v x c; w 

Investigation 






X 


X 






Accept/Reject 
Investigation 






X 


X 






Safety Sign- 
Off 






X 








Generate 
Reports 


X 


X 


X 


X 


X 


X 


Restrictions/ 
Job 

Placements 


X 


X 


X 






X 



Those of ordinary skill in the art of computer 
5 programming will recognize that OHSIM functionality- 
including functionality supported by the EMR, IIM and DAM 
modules may be implemented in a wide variety of different 
graphical user interface (GUI) configurations across a 
plurality of different computing platforms in a variety 
10 of different programming languages. As such, the present 
disclosure will describe user interfaces in terms of 



example functionality that those aspects of the present 
invention may be configured to support. Of course, the 
scope of the present invention is not limited to the 
particular examples or embodiments provided herein. 
5 Preferably, functional aspects of the present 

invention are implemented in a Web-based fashion such 
that user interfaces are viewable and operational via Web 
browser (e.g. Internet Explorer, Netscape Navigator, 
etc.) in operable communication with one or more servers 

10 and associated databases. 

Table 2 correlates several categories of OHSIM 
users with the OHSIM module these users may utilize. 
Notably Table 2 is an example - an unlimited number of 
different users may use any and all OHSIM modules in 

15 connection with occupational health and safety 
activities . 



Table 2 



User Role 


EMR 


IIM 


DAM 


Safety Engineers 




X 


X 


Supervisors & 
Superintendents 




X 


X 


Medical Staff 


X 




X 


Human Resources 


X 






Worker ' s Compensation 


X 







Figure 1 illustrates an overview of the OHSIM 
2 0 system in accordance with a preferred embodiment of the 
present invention. Notably, the content and arrangement 
of Figure 1 may be modified to best fit a particular 
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implementation of the present invention. Aspects of 
Figure 1 are described in greater detail below. 

Electronic Medical Record Module (200) 
5 The EMR module 2 00 provides users access to 

online medical record functionality with which personal 
and occupational medical visits can be documented, viewed 
and updated on a personal or corporate plant / facility 
level. This aspect of the present invention enables a 

10 user to view and update a person's medical history, 

document medical visits, open and update medical leaves 
of absence, generate reports for a person as well, as a 
corporate plant/facility reports, update a person's 
demographic information, view a person's history of 

15 restrictions, and update medical user information. These 
and other features of the EMR module are described in 
greater detail below. 

Figure 2 is a block-flow diagram illustrating a 
methodology or flow-of -events associated with the EMR 

2 0 module according to one embodiment of the present 

invention . 

One aspect of the EMR module supports or 
otherwise enables the creation of an OSHA report having a 
log of OSHA-recordable events that are designated as such 
25 automatically based on the application of OSHA logic to 
data associated with or otherwise characterizing the 
events. These features of the present invention are 
described in greater detail below. 

Figure 3 is a block-flow diagram illustrating a 

3 0 preferred methodology or flow-of -events for recording an 

occupational medical visit using one embodiment of the 
present invention. Depending on the nature and history 
of the medical visit, the visit may be OSHA recordable, a 
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decision that is automatically made as discussed in 
greater detail below. 

A computer- implemented embodiment of the 
present invention receives user-specified data 
5 characterizing an occupational medical visit. First, a 
user may select or otherwise specify an occupational 
treatment facility as represented in block 10. Next, the 
user may query a database of employees for the particular 
injured or ill patient, as represented in block 12. If 

10 no such patient is located, the application provides a 
new patient registration form. 

Next, a check-in form may be completed for the 
injured/ill person, as presented in block 14. Check-in 
information submitted to the form may include the name of 

15 the injured/ill person, the person's date of birth, the 
treatment facility, the visit date and time, the visit 
type (e.g. short, personal, occupational, etc.), and a 
visit association (e.g. whether the visit is a follow-up 
to an existing condition or an initial visit) . 

20 As represented in block 16, an occupational 

detail form is provided for receiving a plurality of 
information relating to the incident. Information may 
include, but is not limited to the location of the 
incident (e.g. on/off premise, plant /building, 

25 department, work location, day, etc.), a date for the 

incident or onset of illness, a description of what the 
injured/ill person was doing before the incident /illness 
occurred, the injured/ill person's personal statement of 
the incident, a health care representative's 

30 interpretation of the statement or injury/illness, the 

object or substance that directly harmed the person, the 
tool /equipment used during the incident, the type of the 
injury/illness, and treatment facility information (e.g. 



physician name, emergency room, overnight, out-patient, 
etc.), an indication as to whether recessitation was 
required, an indication as to whether the person lost 
consciousness, and an indication as to whether the person 
5 died. Notably, certain fields within the occupational 
detail form are utilized by OSHA logic (discussed in 
greater detail below) to determine certain items for 
OSHA-recordable visits (e.g. OSHA log ID, which OSHA 
rules to follow, the creation of an OSHA case, etc.). 

10 As represented in block 18, one or more 

interfaces may be provided for receiving a subjective and 
objective description of the injury/illness as well as an 
indication as to the patient's current medication and any 
objective measurements. According to one embodiment of 

15 the present invention, the subjective/objective 
statements do not affect OSHA recordabili ty . 

As represented in block 20, a variety of forms 
may be provided for receiving input assessing the 
person's injury/illness and adding a diagnosis for same. 

2 0 According to one embodiment, the assessment if via free 
text data entry. A form for adding a diagnosis may be 
provided including items including, but not limited to, 
an indication as to whether the diagnosis is a primary 
diagnosis or not, an indication of the body part 

2 5 affected, an indication as to the laterality of the body 
part, an indication as to whether the diagnosis is a 
simplified diagnosis (e.g. diagnosis selected from a 
drop-down menu) , a flag for whether an illness is 
involved, an ICD-10 diagnosis parameters (e.g. chapter, 

30 main, subcategory 1, subcategory 2, clarification, etc.). 

As represented in block 22, one or more user 
interfaces may be provided enabling users to define a 
plan or treatment for the injured/ill person. The 



treatment /plan may include a free-text description of the 
plan or procedure, treatment orders, medications, 
referrals, restrictions, medical leave, response to 
treatment, test orders, etc. Adding a medication to the 
5 plan/ treatment may include specifying the name of the 
medication, the dosage, the number to dispense, special 
instructions (e.g. DAW, with food, drowsiness 
(precautions), etc.), an indication as to whether the 
medication was dispensed in medical, an indication as to 

10 whether a refill for the medication is available, and if 
so, refill limits, and a medication alert. 

Adding restrictions to the plan/ treatment may 
include the type of restriction (e.g. permanent, 
temporary, etc.), a main category for the restriction, a 

15 begin date, a through date, and a revisit date. Adding a 
medical leave to the plan/ treatment may include 
specifying the type of leave (e.g. personal, 
occupational, etc.), the reason for the leave, the leave 
status, the begin date, the updated date, an indication 

2 0 as to who requested the leave, an indication as to how 
the leave was requested, a description of the reason or 
comments regarding the leave, DROP, the last day worked, 
contact information for the medical leave, and a 
description of the diagnosis. 

2 5 Adding test orders to the plan/ treatment may 

include specifying the type of test, the laterality, the 
order date, the order time, an indication as to whether 
the test was performed in-house or external, an 
indication as to whether a fracture occurred, and a 

30 description of the results or interpretation of the test 
orders . 

As represented in block 24, a visit outcome 

form may be provided in which a user specifies whether or 
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not the injured/ill person is fit for work. This aspect 
of the present invention may affect the OSHA- 
recordability of the visit. Visit outcome information 
may include an indication as to whether the injured/ill 
5 person is fit for work, an indication as to whether a 
revisit is required, an indication as to the date and 
time out, an indication as to whether a worker's 
compensation department should review the event, a 
worker's compensation code (if applicable), and an 

10 indication as to whether this event raises a privacy 
concern for the injured/ill person. 

As represented in block 26, a complete 
verification form may be provided as feedback to the user 
indicating whether or not certain required data input 

15 fields had been properly completed. Figure 4 illustrates 
an example graphical user interface for this aspect of 
the present invention. According to one embodiment of 
the present invention, the complete/verification step 2 6 
triggers the OSHA logic. As discussed in greater detail 

20 below, the OSHA logic 32 is implemented to automatically 
determine based on the input data whether or not the 
event is OSHA- recordable . 

As represented in block 28, an OSHA case 
adjustment form may be provided enabling a user to 

2 5 increase or decrease days away or restricted days for an 

OSHA case. This screen may also display medical leaves 
and/or medical restrictions associated with the visit (s) . 

As represented in block 30, a plurality of 
reports (e.g. regulatory reports, U.S. OSHA, etc.) may be 

3 0 generated. Reports may include an OSHA log of OSHA- 

recordable events, an OSHA injury/illness incident 
report, an OSHA summary report, and an OSHA execution and 
privacy concern summary. Preferably, a plurality of 



user-definable or user-selectable criteria are provided 
for querying a database of received data associated with 
OSHA visits for populating reports generated by the 
present invention. For example, an OSHA log analysis 
5 report may include query parameters such as 

plant/building, calendar year, incident date, incident 
date range, case number, case number range, incident 
department, incident work location, case type (e.g. 
illnesses only, injuries only, etc.), person name, person 

10 ID number, and OSHA cases (e.g. active, closed, etc.). 
Additionally, reports by facility or individual with 
regards to visits, medical leaves and/or medical 
restrictions may be provided. As discussed in greater 
detail below, a work queue may also be provided to assist 

15 medical workers with completing patient visits. 

A "Create Visit" GUI (not shown) enables a user 
to create a new or "original" patient visit, or to open a 
"revisit" (e.g., to open an existing visit for editing or 
entering additional information such as test results) . 

20 Preferably, a search feature is provided enabling a user 
to search among patients (e.g., employees. at a particular 
plant/facility, by treatment facility or corporate-wide 
including by country) . Patients may be searched 
according to demographic information including name, ID 

25 no., treatment facility, plant, etc.). 

If a patient is not found during a search, a 
registration screen is preferably provided enabling the 
user to register the patient within the system. . Patient 
registration may include defining conventional 

30 demographic information as well as the patient's 

plant / facility , medical treatment facility, and employer 
(e.g., in the event that the patient /employee is a 
contract employee) . 



A "Check-In" GUI (not shown) enables a user to 
define a medical visit. Visit types may be defined by 
selecting from a "short", "personal" or "occupational" 
visit identifier. Next, the user defines visit data and 
5 time-in. In accordance with a preferred embodiment, once 
the check- in date and time have been saved by the user, 
they cannot be changed. According to one embodiment, if 
the user selected a "personal" or "occupational" visit, 
the user next selects a "visit association", if 

10 applicable. If the current visit is a new or "original" 
visit, then there is no association. However, if the 
current visit is a follow-up, then the user associates 
the current visit with the original visit that it derives 
from. Preferably, the user is provided with a GUI to 

15 view information regarding any other visits that have 
been associated with an original visit. 

A "Short Visit" GUI (not shown) enables a user 
to quickly define an office visit. Short visits are 
typically used for minor problems that do not require 

20 extensive treatment or testing. Once the short visit 

option has been selected additional fields appear on the 
screen. The visit may be changed to personal or 
occupational at any time before the record is saved. 

Information collected during a short visit may 

2 5 include a primary/ secondary diagnosis, a 

primary/ secondary treatment /order , a data/time out, and 
additional comments, if necessary. Preferably, a primary 
diagnosis is selected from a diagnosis list available for 
short visits. A patient's vital signs may also be input 

30 during a short visit. 

Preferably, a user is provided with links to 
view various categories of information associated with 
the current patient. For example, links may be provided 



for a patient's complete visit history, or only visits 
deriving from the current original visit. Additional 
links may provide a user with a person's medical, 
medication and allergy history, current and historical 
5 patient restrictions, and staff notifications/messages, 
etc . 

For First Time Occupational Visits (FTOVs) , a 
GUI may be provided (not shown) in which the user inputs 
the details of an occupational incident. FTOV 

10 information to be input may include the location of the 
incident (plant, building, department, bay, etc.), the 
date/ time of the incident, a description of what the 
patient was doing just prior to the incident, the 
patient's account of the incident, a user's (e.g., health 

15 care representative's) interpretation of the patient's 

account, the objects /substances that caused the incident, 
the tool /equipment being used at the time, the 
injury/illness type, indications as the whether 
resuscitation was required, whether the patient lost 

2 0 consciousness, and whether the patient died. Preferably, 
treatment facility information includes the name of the 
associated physician or health care professional, the 
location where the person was treated, etc. 

For personal and occupational visits, the user 

2 5 may also input subjective statements, such as a person's 
description of the reason for a visit, information on 
history or healthcare problems into a "Subjective" EMR 
GUI. Preferably, data entered in the person's personal 
account (described above) is automatically copies to the 

30 Subjective GUI in a first time occupational visit. It is 

additionally preferred that once this data is saved, it 

cannot be edited. Current medications documented in the 

person's record may also be displayed. 
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An "Objective" GUI (not shown) may be provided 
for recording clinical observation information (i.e., 
factual and measurable data - vital signs, body mass 
index, physical condition, etc.) regarding the person's 
5 medical condition at the time of the visit. 

Figure 5 is an example GUI for defining a 
diagnosis in accordance with one embodiment of the EMR 
aspect of the present invention. Selections 16 determine 
whether the diagnosis is a primary or otherwise. 

10 Preferably, up to four diagnoses may be entered. Drop- 
down menu 18 enables a user to select injured body 
part(s). Drop-down menu 20 enables a user to select the 
laterality for the injury. 

A user may specify a "Simplified Diagnosis" 

15 from drop-down menu 22, or define a diagnosis from among 
the International Statistical Classification of Diseases 
and Related Health Problems (ICD) from among drop down 
menus 24. ICD classifications can be obtained from the 
Center for Disease Control and Prevention, 1600 Clifton 

20 Rd., Atlanta, GA 30333. 

Preferably, the selection 24 made at each level 
determines selections that are available in the next 
level of the hierarchy. The preferred pathway is: 
Chapter, Main, Sub-Category 1, Sub-Category 2 (if 

25 applicable) and Clarification (if applicable) . While 
laterality and body part are not applicable for every 
diagnosis, documentation when appropriate is important in 
maintaining an accurate medical record. 

Occupational diagnoses may be documented using 

30 the "ICD" or "Simplified Diagnosis pathways." When using 

the Simplified Diagnosis pathway, the corresponding ICD 

automatically displays based on a combination of body 

part, laterality, and Simplified Diagnosis selections. 
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Preferably, a "Plan" GUI is provided enabling a 
user to input interventions for resolving the patient 1 s 
problem or injury. A "medication" form allows a user to 
delete or view prescription/non-prescription medications 
5 already ordered for a patient during the current visit, 
order new medications, and complete medication order 
forms for medications to be given outside of the medical 
department. Ordering new medications preferably includes 
defining the name of the medication, the dosage, specific 

10 dosage instructions, the number to dispense, the number 
of refills, and any alerts (e.g., allergy alerts) . 
Preferably, medications and immunizations that are 
ordered during a patient visit are automatically entered 
into the person's medical history. 

15 Functionality for printing prescriptions may 

also be provided. Preferably, user-access to the 
prescription printing functionality is restricted based 
on user ID or role. A "Dispense Medication/Immunization" 
GUI (not shown) enables authorized users to document 

20 details regarding dispensed medications/immunizations. 

Information to be submitted may include a "Route" if the 
medication is given intramuscular, subcutaneous or 
intradermal. Additional information for immunizations 
may include Series, Booster, Brand, Manufacturer, Lot 

2 5 Number, Expiration Date, Amount, Route, Site, Date and 
Time of Immunization, Next Due Date, etc. 

A "Test Orders" GUI (not shown) enables a user 
to view, delete or add orders for patient tests. Test 
orders may include an audiogram, a breathalyser, an 

30 electrocardiogram, an electroencephalogram, 

electromyogram, blood work, urine test, pulmonary 
function tests, a radiology exam, a scan, a sleep apnea 
examination, a treadmill test, an ultrasound, a vision 



test, and user-defined tests (i.e., free-text 
description) . The GUI may provide the user with data 
entry/selection fields for defining the date of the 
order, the date of the test, the test results, the entity 
5 to perform the test, and/or test conclusions. 

A "Treatment Orders" GUI (not shown) enables a 
user to view, delete or add orders for patient treatment. 
Treatment orders may include medical goods such as an ace 
wrap, arm sling, band aid, brace, cane, clavicle strap, 

10 crutches, etc., or wound care such as antibiotic 

ointment, butterflies, dry and wet dressing, dressing 
pressure, drainage, etc. 

A "Response to Treatment /Observation" GUI (not 
shown) enables a user to input a patient's response to 

15 treatments and any significant clinical observations. 
Preferably, this is performed in a free-text fashion. 

A "Referral" GUI (not shown) enables a user to 
add, view or delete current referral orders. Defining a 
referral includes specifying the referral type (e.g., 

20 specialist, etc.), the scope of the requested referral 
(e.g., evaluation, treatment, both), a referral name, 
address, telephone number, etc., an appointment date and 
time, and special instructions or comments. 

A "Medical Restrictions" GUI (not shown) 

2 5 enables a user to view all open restrictions or expired 
restrictions with a revisit date (even if the 
restrictions is not within the current visit series) , 
print a report listing all open restrictions, add a new 
restriction for the current visit, attach a restriction 

30 if this is a revisit in the. same series of visits, 

unattach a restriction from the current visit if attached 
in error, edit a restriction from a "Restrictions for 
Current Visit" table, and delete a restriction from the 



"Restrictions for Current Visit" table. Adding a new 
restriction may involve defining the type of the 
restriction (e.g., temporary, permanent, etc.), a 
category for the restriction, a begin date, an end or 
5 thru date, and a revisit date. 

A "Medical Leave" GUI (not shown) enables a 
user to view open and pre-scheduled medical leaves, view 
and edit closed and deleted medical leaves, attach an 
existing leave not previously attached to a visit, attach 

10 an open leave to a revisit in a series of visits, and 

begin a new "Unfit for Work" leave. In accordance with a 
preferred .embodiment of the present invention, medical 
leaves are divided into four main categories: open, pre- 
scheduled, closed, and open/closed. Open medical leaves 

15 a reoccurring open medical leaves. Pre-scheduled leaves 
are used when a person knows in advance that they will be 
going on leave (e.g., for a scheduled surgery). 
Preferably, leaves can only be closed by an authorized 
health care representative. "Open/closed" leaves are for 

2 0 "Unfit for Work" medical leaves - when a person goes out 

on a medical leave but the leave is not entered into the 
OHSIM system. 

Opening a new medical leave may include 
defining the type of leave (e.g., personal, 
25 occupational), the reason for the leave (e.g., unfit to 
work, etc.), the begin date, the end date, the update 
date, the requestor, the manner requested, comments, the 
last day worked, contact information for the patient 
during the leave, and a diagnosis. 

3 0 A "Visit Outcome" GUI (not shown) enables a 

user to summarize the medical visit, including whether 
the person is fit to work, needs medical restrictions, 
etc. This interface allows a user to record a 



disposition for the visit. To do so, the user may select 
or otherwise define an overall disposition, an indication 
as to whether a revisit is necessary, and if so, when. 
Additional user-definable/selectable information may 
5 include an indication as to whether the worker's 
compensation department should review the visit, a 
worker's compensation code, or an indication as to 
whether the visit poses a privacy concern for the 
patient . 

10 Preferably, a "Complete Verification" screen is 

provided to the user indicating whether the extent to 
which any required fields in the GUIs (described above) 
have been completed. 

In accordance with a preferred embodiment of 

15 the present invention, OSHA logic is applied to the visit 
information upon a successful verification that all 
required data has been entered. This feature of the 
present invention will be discussed in greater detail 
below. 

2 0 Figure 6 is an example GUI for implementing an 

OSHA log analysis in accordance with the present 
invention. Notably, an OSHA log report may be generated 
on multiple levels of granularity (e.g., by date, plant, 
department, work location, person, etc.) Selection 

25 criteria for the analysis may include a plant /building 

26, a calendar year 28, an incident date range 30, a case 
number range 32, an incident department, an incident 
location, a case type, and personal identification 
information for a person- specific search . 

30 
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OSHA Logic 

Tables 3 through 9 contain example business 
rules and processing logic for processing visit data and 
generating reports, including formal OSHA log reports. 
5 For example, business rules and logic such as that 

exhibited in Tables 3 through 9 may be executed by the 
OHSIM application to process and automatically identify 
visits that are OSHA-recordable (e.g., visits to be 
included in an official OSHA log) . This automated aspect 

10 of the present invention reduces or eliminates error and 
inconsistency typically associated with the conventional 
"human- implemented" decision making process to determine 
which visits are OSHA-recordable. 

Notably, the business rules and processing 

15 logic contained in Tables 3 through 9 are only examples 

to assist in the understanding and implementations of the 
present invention. Tables 3 through 9 are not intended 
to limit the scope or application of the present 
invention . 

20 

Table 3 

Example OSHA Case Number Definition 

OSHA Case numbers may be generated based on the following 
criteria: 

Date of Incident 

Incident Plant /Building and OSHA Log ID selection 

combination 

Case Number Format/Layout: #####-YY-NNNNN 
##### = OSHA Log ID 

• This number may represent the Plant /Building code or 
a variation thereof 

• YY = 2-digit year (based on Date of Incident) 

• NNNNN = automatically system generated sequential 
number 



24 



Table 4 



Example Triggers to Call OSHA Logic 

(1) Whenever an Occupational Original Visit (also known 
as TOV-First Time Occupational Visit) is completed 

or the first time . 

(2) Whenever an Occupational Original Visit (also known 
as TOV-First Time Occupational Visit) is deleted, 

(3) Whenever an Occupational Revisit is completed for 
the first time . 

(4) Whenever an Occupational Revisit is deleted. 

For any of the following triggers, the visit involved 

is assumed to have been completed for the first time . 

(1) Whenever the Complete Verification Tab is selected 
on any Occupational Visit. 

(2) Whenever the Visit Type changes. 

• A visit/visit series changes from "Occupational" to 
" Personal " . 

• A visit /visit series changes from "Personal" to 
"Occupational" . 

(3) Whenever Visit Association changes. Visit 
Association changes are done via the View/Update 
Visit Information Task on the Navigation Frame. For 
example, an (occupational) Original Visit changes to 
an (occupational) Revisit (i.e. VI becomes V2c) . 

An (occupational) Revisit changes to an 
occupational) Original Visit (i.e. V3b becomes 
V4), or an (occupational) Revisit is linked to a 
different (occupational) Original Visit (i.e. V3b 
becomes V4c) . 

(4) Whenever changes are made to the Occupational Detail 
screen. This includes adding, changing/updating, or 

deleting information from the screen. 

(5) Whenever changes are made to the Primary Diagnosis 
of any Occupational Visit. This includes adding, 
changing/updating, or deleting the Primary 
Diagnosis. This includes changing the Illness Flag 
on the Primary Diagnosis from "Yes" to "No" OR "No" 
to "Yes". 

(6) Whenever changes are made to Prescription or Non- 
Prescription/Prescription Strength MEDICATION that 
are associated to an Occupational Visit. This 
includes adding or deleting. NOTE: If a 
Prescription or Non- Prescript ion/ Prescript ion 
Strength MEDICATION is added via an occupational 
visit, but is DELETED outside of the occupational 
visit series, the OSHA Logic may not be called until 

the Complete Verification Tab is selected in any 
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(occupational) visit within the series to which the 
Medication was associated. 

(7) Whenever changes are made to the Fracture field on 
the Radiology screen under the Test Orders Tab. 

(8) Whenever changes are made to the Treatment Orders 
screen . 

(9) Whenever the Referral Type field changes to or from 
" PHYSICAL THERAPY" on the Referral screen. 

(10) Whenever changes are made to the Medical Restriction 
screen. This includes Adding, Extending, Updating, 

and Deleting medical restrictions. • 

(11) Whenever changes are made to the Medical Leave 
screen. This includes the Adding, Extending, 
Updating, Closing, and Deleting medical leaves. In 
other words, as long as there is an Originating 
Visit attached to the Medical Leave, whenever the 
leave screen is updated, in or outside of a visit, 

OSHA logic will be triggered. 

(12) Whenever changes are made to the Visit Outcome field 
on the Visit Outcome screen. 

(13) Whenever changes are made to the OSHA Case 

Adjustments screen . 



Table 5 

Example OSHA Logic Processing 
DETERMINATION OF THE OSHA LOG: 

• The OSHA Log to which the Incident belongs is based 

upon the INCIDENT PLANT /BUILDING selected and the 
OSHA Log ID associated to the plant /building 
selected. 

The INCIDENT PLANT /BUILDING selected may have more 
than one OSHA Log associated to it. 

_• An Incident may be assigned to ONE OSHA Log 

WHICH OSHA RULES ARE FOLLOWED: 

There are TWO Sets of OSHA Rules that may be 
followed, based on the Date of Incident. 

• OSHA 200 rules apply if the Date of Incident is 

PRIOR to 1/1/2002 

• OSHA 300 rules apply if the Date of Incident is ON 

or AFTER 1/1/2002 
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WHEN IS OSHA LOGIC PROCESSED: 

• OHSIM will process OSHA Logic (based on the triggers 

noted above) EXCEPT under the following conditions: 

• The Date of Incident occurred in a year 6 years 

PRIOR to the current calendar year. 
The Original Visit is created ON or AFTER 
1/1/2002, but the Date of Incident is PRIOR to 
1/1/2002 . 

A Revisit is created ON or AFTER 1/1/2002, but 
the Date of Incident is PRIOR to 1/1/2002. 

• OSHA Logic will be processed for any OSHA CASE 
ADJUSTMENTS made regardless of when the Adjustment was 
created and/or the Date of Incident. 



Table 6 



Example Factors Making Visit OSHA Recordable 



OCCUPATIONAL DETAIL FORM 

• Person loses consciousness 

• Person dies 



ASSESSMENT FORM 

The PRIMARY Diagnosis is used in determining OSHA 
recordabi 1 i ty 

• Certain (Primary) Diagnosis Codes by 

themselves can make an incident OSHA 
Recordable . 

A code system may be created to help 
identify such Diagnosis codes. 
The illness Flag of the Primary Diagnosis 
together with the actual Diagnosis may 
play a part in determining which OSHA 
rules to follow. See table below. 





Example recordable code 


values 


are as 


follows : 










OSHA 


Rules 


Code 


Code Description 














200 


200 


300 


300 






INJ 


ILL 


INJ 


ILL 


1 


RRRR- 2 INIL-3 INIL 


R 


R 


R 


R 


2 


RRRNR- 2 INIL-3 INIL 


R 


R 


R 


NR 


3 


RRNRR-2 INIL- 3 INIL 


R 


R 


NR 


R 


4 


RRNRNR- 2 INIL-3 INIL 


R 


R 


NR 


NR 


5 


NRRRR- 2 INIL-3 INIL 


NR 


R 


R 


R 


6 


NRRRNR- 2 INIL-3 INIL 


NR 


R 


R 


NR 


7 


NRRNRNR- 2 INIL- 3 INI L 


NR 


R 


NR 


NR 


8 


NRRNRR- 2 INIL-3 INIL 


NR 


R 


NR 


R 



R = Automatically Recordable 
NR = Not Automatically Recordable 



PLAN /TREATMENT FORM - TREATMENT ORDERS 

Certain Treatment Codes can make an incident OSHA 
Recordable. In order for a treatment code to make 
an incident OSHA recordable, the flag for the 
following items for the selected treatment code 
must be equal to "Y" . 

( 1 ) BOHS7 4 0_LU_TREATMENT . OHS7 4 0_2 0 0_ALWAYS_REC_F 

• If this flag is set to yes it means that 
the Treatment code is automatically 
recordable : 

a. as long as the Date of Incident is 
prior to 1/1/2002 

b. regardless if the treatment occurs in 
a New Visit or Revisit 

( 2 ) B0HS7 4 0_LU_TREATMENT . OHS7 4 0_2 0 0_ALWAYS_REVIS_F 

• If this flag is set to yes it means that 
the Treatment code is automatically 
recordable : 

a. as long as the Date of Incident is 



- 28 - 



prior to 1/1/2002 
b. only when the treatment occurs in a 
Revisit 

( 3 ) BOHS7 4 0_LU_TREATMENT . OHS7 4 0_3 0 0_ALWAYS_REC_F 
If this flag is set to yes it means that 
the Treatment code is automatically 
recordable : 

a. as long as the Date of Incident is on 
or after 1/1/2002 

b. regardless if the treatment occurs in 
a New Visit or Revisit 

• If the Treatment = Durable Medical Goods, 
there are certain durable medical goods 
that can make an incident OSHA recordable. 
In order for durable medical goods that 
can make an incident OSHA recordable, the 
following terms must be equal to "Y" . 

( 4 ) BOHS7 4 6_LU_DUR_MED . OHS7 4 6_2 0 0_ALWAYS_REC_F 

• If this flag is set to yes it means that 
the Durable Medical Goods code is 
automatically recordable: 

a. as long as the Date of Incident is 
prior to 1/1/2002 

b. regardless if the durable medical 
good occurs in a New Visit or Revisit 

( 5 ) BOHS7 4 6_LU_DUR_MED . 0HS7 4 6_3 0 0_ALWAYS_REC_F 

If this flat is set to yes it means that 
the Durable Medical Goods code is 
automatically recordable : 

a. as long as the Date of Incident is on 
or after 1/1/2002 

b. regardless if the treatment occurs in 
a New Visit or Revisit 

• If the Treatment = Wound Care, there are 
certain wound cares that may make an 
incident OSHA recordable. In order for 
wound cares to make an incident OSHA 
recordable, the following terms must be 
equal to "Y" . 

( 6 ) BOHS7 4 8_LU_WND_CA . OHS7 4 8_2 0 0_ALWAYS_REC_F 

If this flat is set to yes it means that 
the Wound Care code is automatically 
recordable : 

a. as long as the Date of Incident is 
prior to 1/1/200 

b. regardless if the wound care occurs 
in a New Visit or Revisit 

( 7 ) B0HS74 8_LU_WND_CA . OHS7 4 8__3 0 0_ALWAYS_REC_F 

If this flag is set to yes it means that 
the Wound Care code is automatically 
recordable : 
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a. as long as this Date of Incident is on 
or after 1/1/2002 

b. regardless if the wound care occurs 
in a New Visit or Revisit 



PLAN / TREATMENT FORM - Medications 



Certain medications can make an incident OSHA 
Recordable. If the medication selected is either 
PRESCRIPTION or NON-PRESCRIPTION/PRESCRIPTION 
STRENGTH, then the incident may be OSHA recordable. 



PLAN / TREATMENT FORM - Test Orders 



If the Test Order of "Radiology" is selected AND the 
Fracture? field is designated as "Y",l then the 
incident is OSHA recordable. 



PLAN /TREATMENT FORM - Referrals 

If the referral type selected is PHYSICAL THERAPY 
then the incident is OSHA recordable. 



PLAN /TREATMENT - Medical Leave 

• A Medical Leave (with an originating visit) : 
IS NOT automatically recordable if it is 
created PRIOR to the data transfer from 
TWOS/OHS to OHSIM 
• . IS automatically recordable (regardless of the 
Visit Outcome) if it is created AFTER the data 
transfer from TWOS/OHS to OHSIM, and the 
incident has a Date of Incident prior to 
1/1/2002 

• IS automatically recordable (regardless of the 
Visit Outcome) if it is created after the data 
transfer from TWOS/OHS to OHSIM, and the 
incident has a Date of Incident on or after 
1/1/2002, unless the medical leave is only for 
one day and that day equals the Date of 
Incident. 



PLAN /TREATMENT - Medical Restrictions 

A Medical Restriction: 

IS NOT automatically recordable if it is 
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created before the data transfer from TWOS/OHS 
to OHSIM 

• IS automatically recordable (regardless of the 
Visit Outcome) if it is created after the data 
transfer from TWOS/OHS to OHSIM, and the 
incident has a Date of Incident prior to 
1/1/2002 

• IS automatically recordable (regardless of the 
Visit Outcome) if it is created after the data 
transfer from TWOS/OHS to OHSIM, and the 
incident has a Date of Incident on or after 
1/1/2002, unless the medical restriction is 
only for one day and that day equals the Date 
of Incident. 



VISIT OUTCOME FORM 

• Certain Visit Outcomes will make an incident OSHA 
Recordable. For a visit created before the data 
transfer from TWOS/OHS to OHSIM, do the following: 

(1) Always record a case if the Visit Outcome=fit 
for work with restrictions 

(2) Always record a case if the Visit Outcome=unf i t 
for work 

For a visit created after the data transfer from 
TWOS/OHS to OHSIM, and with a Date of Incident 
before 1/1/2002: 

(1) Only a Visit Outcome=unf i t for work is 

automatically recordable (regardless of the 
Date of Incident) . 

• For a visit created after the data transfer from 
TWOS/OHS to OHSIM, and with a Date of Incident 
on/after 1/1/2002, do the following: 

(1) A Visit Outcome=unf it for work is automatically 
recordable unless the Visit Date equals the 
Date of Incident. 



Table 7 



Example Contents of OSHA Log 



Primary Diagnosis Rules: 

• For any OSHA Cases created PRIOR to conversion, the 
following applies with regards to the PRIMARY 
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DIAGNOSIS : 

(1) The Primary Diagnosis information appears under 
a Description of Injury/Illness column for the 
200 Log. 

(2) The Primary Diagnosis displayed on the OSHA Log 
is that of the visit that created the OSHA Case 
unless the case is modified. 

a) If an OSHA Case (created prior to 
conversion) is modified after conversion 
but PRIOR to 1/1/2002, then the Primary 
Diagnosis displayed is that of the most 
recent visit with the INCIDENT year within 
the series of visits for the OSHA Case. 

b) If an OSHA Case (created prior to 
conversion) is modified after conversion 
but ON or AFTER 1/1/2002, then the Primary 
Diagnosis displayed is that of the visit 
that created the OSHA Case. 

For any OSHA Cases created AFTER conversion, the 
following applies with regards to the PRIMARY 
DIAGNOSIS: 

(1) The Primary Diagnosis information appears under 
a Description of Injury/Illness column for the 
200 Log and under a Describe injury or illness, 
parts of body affected, and object/substance 
that directly injured or made person ill column 
for the 3 00 Log. 

(2) The Primary Diagnosis displayed on the OSHA Log 
is that of the most recent visit within the 
series of visits for the OSHA Case. 

PRIVACY CONCERN RULES: 

These Rules ONLY apply to those cases with a Date of 

Incident ON or AFTER 1/1/2002. 
• An Incident is considered to be of Private Concern 

when one (or any combination) of the following 

occurs : 

(a) The primary diagnosis selected has been flagged 
as sensitive 

(b) The body part associated to the primary 
diagnosis has been flagged as sensitive 

(c) The yes radio button is selected for the 
privacy concern field on the visit outcome 
screen 



Wherever Primary Diagnosis and/or Body Part is 
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mentioned (throughout this section) , it is referring 
to the primary diagnosis of the MOST RECENT visit 
within the visit series. 

When the Privacy Concern Rules are applied, 
depending 

on the circumstance, the OSHA Log may display 
information in the following manner: 

(a) Circumstance : 

PRIMARY DIAGNOSIS BODY PART PRIVACY CONCERN FIELD (V.O.) 
Sensitive Non-Sensitive No 

Sensitive Non-Sensitive Yes 

Non-Sensitive Non-Sensitive Yes 

Display : 

• A column will display "Privacy Concern Case" 

• A column will display "Privacy Concern Case" /Actual 
Body Part Description/Laterality 

• A column will NOT display Object or Substance 

(b) Circumstance : 

PRIMARY DIAGNOSIS BODY PART PRIVACY CONCERN FIELD (V.O.) 



Sensitive Sensitive No 

Sensitive Sensitive Yes 

Non-Sensitive Sensitive No 

Non-Sensitive Sensitive Yes 



Display: 

• A column will display "Privacy Concern Case" 

• A column will display "Privacy Concern Cast " /Sensitive 
Body Part Description/Laterality 

• A column will NOT display Object or Substance 
( c ) Circumstance : 

PRIMARY DIAGNOSIS BODY PART PRIVACY CONCERN FIELD (V.O.) 
Non-Sensitive Non-Sensitive No 

Display : 

• A column will display "Person's Name" 

• A column will display Actual Diagnosis 

Description/Actual Body Part Description/Laterality and 
Object or Substance information 



ILLNESS CASES RULES: 

• For Illness Cases with PERMANENT restrictions. 

On the OSHA 2 00 Log (Date of Incident is PRIOR to 
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1/1/2002), enter an asterisk in an appropriate 
illness column. 

On the OSHA 300 Log (Date of Incident is AFTER 
12/31/2001), DO NOT enter an asterisk. 



OSHA LOG CHECKMARKS: 



OSHA Logic may check illness data tables for OSHA 
Recordable cases in order to determine where 
particular checkmarks would be placed on the OSHA 
Log 

OSHA Log Injury/ Illness Specific Values - PLACEMENT Flag 

OSHA 2 00 
Description : 



O No Placement 

A Occupational skin diseases or disorders 

B Dust Diseases of the lungs 

C Respiratory conditions due toxic agents 

D Poisoning 

E Disorders due to physical agents 

F Disorders associated with repeated trauma 

G All other occupational illnesses 

OSHA 3 00 

Description : 

0 No Placement 

1 Injury 

2 Skin disorder 

3 Respiratory condition 

4 Poisoning 

5 All Other Illness 



Table 8 



OSHA Counting (200 Logic) 



GENERAL ASSUMPTIONS: 

• This counting logic applies to occupational 
visits with a Date of Incident PRIOR to 1/1/2002. 

• All examples imply a Date of Incident < 1/1/2002. 

• Counting refers to restricted days and/or days away. 

• ■ Count Monday through Friday only using the 

corporate calendar and exclusive of known 
corporate holidays. 

Wherever there is an overlap in the date ranges 
between Days Away and Restricted Days, Days Away 
wi 1 1 override . 

• The counting logic provided within this section 
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applies to ALL OSHA cases unless otherwise 
specified. 

COUNTING OF RESTRICTED DAYS: 

Permanent Restrictions 
•DO NOT count restricted days for a permanent restriction 

• Visit Outcome 

•COUNT a restricted day for Visit Outcomes=UNFIT FOR 
WORK, UNLESS the Date of Incident equals the Visit Date, 
then do NOT count a restricted day. 

• OSHA Case Adjustment 

• Count all adjustments related to the 
increase or decrease of restricted days 
regardless of when the Adjustment was 
created and regardless of the Date of Incident. 

Counting of Days Away: 

• Count Days Away inclusive of the Begin Date 
through the End Date, unless otherwise specified. 

• NEVER count a day away where the Date of Incident 
equals the Begin Date of a leave. 

Count Days Away for a medical leave based on 
justification . 

• NEVER count Days Away for a medical leave 
where the days are NOT Justified. 

• Count Days Away inclusive of the Begin Date 
through the End Date, unless otherwise 
specified . 

• NEVER count a day away where the Date of 
Incident equals the Begin Date of a leave. 

• Count Days Away for a medical leave based on 
justification . 

• NEVER count Days Away for a medical 

leave where the days are NOT Justified. 

• OSHA Case Adjustment 

•Count all adjustments related to the increase or 
decrease of days away regardless of when the Adjustment 
was created and regardless of the Date of Incident. 

NOTE: The OHSIM system will NOT allow an 
adjustment to include the Date of Incident. 

Requirement to Update OSHA Records: 

• Update OSHA case records for 5 years following 
the end of the calendar year (for the date of 
injury/onset of illness) to which the records 
relate: 

• Review visits for 5 years following the end of 
the year (for the date of injury/onset of 
illness) to which the record relates. 
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• If recordable, enter an individual case entry 
(e.g., J. Smith's sprain with injury date of 
3/10/1998) on the Log for the year of injury/onset 
of illness date (e.g., John's case on the 1998 Log). 
If changes occur related to the case with regard to 
recordability or counting, update the individual 
case entry for a maximum of 5 years following the 
end of the calendar year (for the injury/onset of 
illness date) to which the record relates. Reflect 
any adjustments related to the individual case entry 
on that Log. 

• Update the Log year-to-date totals (the totals 
for each column on the last page of that Log) if 
changes are made to the individual case entry. 

• Prepare the Annual Summary totals for printing. 

Table 9 



OSHA Counting (3 00 Logic) 



GENERAL ASSUMPTIONS: 

This counting logic ONLY applies to occupational 
visits with a Date of Incident ON or AFTER 
1/1/2002 . 

All examples imply a Date of Incident 1/1/2002. 

• Counting refers to restricted days and/or days 
away . 

• Count ALL calendar days, regardless of whether or 
not the employee was normally scheduled to work. 
(This includes all weekends and holidays.) 
Wherever there is an overlap in the date ranges 
between Days Away and Restricted Days, Days Away 
will override . 

CAP the total Count of Restricted Days and/or 
Days Away at 180 calendar days. (i.e. Days 
Away=100, and Restricted Days=100, Total Days 
Counted still equals 180) . All restricted days 
and days away are associated with occupational 
cases . 

• The counting logic provided within this section 
applies to ALL OSHA cases unless otherwise 
specified. 

COUNTING OF RESTRICTED DAYS: 

• Restrictions 

•Count restricted days inclusive of the Begin Date 
through the End Date, unless otherwise specified. 

•DO NOT count a restricted day where the Date of Incident 
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equals the Begin Date of a restriction. 

• Permanent Restrictions 

•If an OSHA Case has a Permanent Restriction associated 
to it, make sure that at least ONE restricted day is 
entered. 

• Visit Outcome Field 

•A Visit Outcome-UNFIT FOR WORK will be counted as a 
restricted day, UNLESS the Date of Incident EQUALS the 
Visit Date. 

• OSHA Case Adjustment 

Count all adjustments related to the increase or decrease 
of restricted days regardless of when the Adjustment was 
created and regardless of the Date of Incident. 

COUNTING OF DAYS AWAY: 

• Medical Leaves (with an originating visit) 

•Count Days Away inclusive of the Begin Date through the 
End Date, unless otherwise specified. 

•DO NOT count a day away where the Date of Incident 
equals the Begin Date of a leave. 
•Count Days Away for a medical leave based on 
justification . 

►NEVER count Days Away for a medical leave where 
the days are NOT Justified. 

OSHA CASE ADJUSTMENT: 

• Count all adjustments related to the increase or 
decrease of days away regardless of when the 
Adjustment was created and regardless of the 
Date of Incident. 

NOTE: The OHSIM system will NOT allow an 
adjustment to include the Date of Incident. 

REQUIREMENT TO UPDATE OSHA RECORDS: 

• Update OSHA case records for 5 years following 
the end of the calendar year (for the date of 
in jury /onset of illness) to which the records 
relate : 

•Review visits for 5 years following the end of the year 
(for the date of injury/onset of illness) to which the 
record relates. 

• If recordable, enter an individual case entry 
(e.g., J. Smith's sprain with injury date of 
3/10/1998) on the Log for the year of injury/onset 
of illness date (e.g., John's case on the 1998 Log). 

•If changes occur related to the case with regard to 
recordability or counting, update the individual case 
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entry for a maximum of 5 years following the end of the 
calendar year (for the injury/onset of illness date) to 
which the record relates. Reflect any adjustments 
related to the individual case entry on that Log. 

Update the Log year-to-date totals (the totals 
for each column on the last page of that Log) if 
changes are made to the individual case entry. 
• Prepare the Annual Summary totals (vertically 

total columns G through L and Ml through M7 ) . 



- 38 - 



OHSIM Reports 

The OHSIM system is configured to present 
processed health and safety data in a plurality of 
5 different reports and report formats. 

"Incident Reports" compile and display 
information collected during a patient visit or re-visit. 
A user is provided with selectable criteria to customize 
a report (e.g., for incidents at a plant, for a 
10 particular individual, etc.). As discussed in greater 

detail with regard to the IIM, plant level clinicians and 
others may view incident investigations reports resulting 
from a reported incident. 

An OSHA Log may be the official Occupational 
15 Safety and Health Administration (OSHA) Log. An OSHA Log 
Analysis provides selection criteria to customize what is 
displayed on the Log. An OSHA Injury/Illness Incident 
report provides information from a medical visit (in 
particular occupational detail information) for 

2 0 particular OSHA Case(s). The report provides . 

supplementary information regarding Case(s) on the log. 
An OSHA Summary may be used to meet employee-posting 
requirements in accordance with OSHA requirements. An 
OSHA Execution report provides information regarding 
25 Occupational Medical Visit activity. An OSHA Inj/Ill 

Incident for Authorized Employee Representatives provides 
information from a medical visit (in particular, 
occupational detail information) for particular OSHA 
Case(s). This report provides Case supplementary 

3 0 information regarding a Case(s) on the OSHA Log and is 

available to Authorized Employee Representatives as 
defined by OSHA. A Privacy Concern Case report provides 
confidential information related to privacy concern cases 
as defined by OSHA. 



A "Medical Leaves by Facility" report displays 
leaves in selected statuses for selected or user role- 
defined plant/building(s) . Selection criteria allows a 
user to customize the data display by a particular 
5 department or work location as well as by leave type 

(personal or occupational) and active, unattached, NWA, 
and deleted. A user can also search by leave status 
(closed, open, open-closed and pre-scheduled) . In 
addition, the report can be sorted by leave end date, 

10 employee name, work location, etc. 

A "Medical Restrictions by Facility" report 
enables a user to view all individuals with restrictions 
in selected statuses for selected plant /building (s) . 
Selection criteria allow a user to customize data display 

15 by selecting a visit type (personal or occupational) and 
status (active, deleted, expired, and expired with a 
revisit date) . In addition, the report can be sorted by 
restriction end date, employee name, or work location. 

A "Medical Visits by Facility" report is a 

20 visit log for a^ particular treatment facility. Selection 
criteria allows a user to customize the report by 
selecting a visit type (FTOV, Occupational, Personal, or 
Short) as well as a date range. In addition, a user can 
customize the data display by selecting a Sort By option 

25 (Person Name, Visit Type, Visit Outcome, Last Updated By, 
or Work Location) . A user can search within any date 
range. Preferably, if the date range is thirty-one days 
or less, the report is available online. If the date 
range is greater than thirty-one days, the report is a 

3 0 batch report and will not be available for immediate 
viewing . 

A "Medical Revisit" report allows a user to 
print a report of all scheduled medical revisits. A user 
can search by date multi-day increments (e.g., up to 31- 
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day increments) . Preferably, the printed report separates 
required revisits, restriction revisits, medical leave 
revisits, and immunization revisits onto separate sheets. 

A "Medical Restrictions by Individual" report 
5 allows a user to view the medical restriction history for 
a person. Selection criteria allows a user to customize 
the data display by selecting a visit type (personal or 
occupational) and status (active, deleted, expired, and 
expired with a revisit date) . In addition, the report 

10 can be sorted by restriction end date, employee name, or 
work location. 

A "Medical Leave by Individual" report allows a 
user to view the medical leave history for an individual, 
the data display by selecting a leave type (personal or 

15 occupational) and active, unattached, NWA, and deleted. A 
user can also search by leave status (closed, open, open- 
closed and Pres-scheduled) . In addition, the report can 
be sorted by leave type, leave begin date, and OSHA case 
number . 

2 0 A "Visit Summary by Individual" report allows a 

user to print a report of all visits to the Medical 
Department for a particular person. A user can elect to 
print only OSHA, occupational or personal visits with 
associated revisits or visits for a date range. An 
25 original or OSHA visit with associated revisits selection 
typically result in an immediate online report. A 
Multiple Visits by Date Range selection is preferably 
implemented in a batch report. 

In addition to the "standard" reports described 

3 0 above, the OHSIM system is capable of and configured to 

implement custom analytical reporting. This aspect of 
the present invention is described in greater detail in 
accordance with the detailed description of the DAM 
module . 
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Table 10 contains a descriptive summary of task 
menu links that may be implemented in accordance with the 
EMR module GUIs and reports described in greater detail 
above. Notably, this descriptive summary depicts a 
preferred implementation of the EMR module, and is not 
intended to limit the scope of the present invention. An 
unlimited number of related tasks and corresponding role 
combinations may be implemented within the scope of the 
present invention . 



TABLE 10 


Task Link 


Description 


HOME 


Returns you to the OHSIM Welcome 
Page 


CODE A VISIT 


Access to visits for coding. You 
have access to all information 
within a visit as well as 
associated revisits to allow a 
coding decision. 


MEDICAL TASKS 


Expands to show a list of tasks 
related to a person. 


- Change Person 


Change the name of the person on 
whom you want to enter information 
if you have been in another 
person's visit or history. 


- Create Visit 


Create a new visit or revisit. 


- View/Update 
History Information 


Add information to or view a 
person's medical history without 
opening a visit. 


- View History 
Information 


View a person's medical history. 


- View/Update 
View/Update Visit 
Information 


Update a person's demographic 
Reopen an existing visit for 
eaiciny , view une visil suiumary ior 
a selected visit; Change the visit 
association for existing visits. 


View Visit 
Information 


View visit information. 


Batch Report 
Status 


Used to view the status of a batch 
report request . 


Incident 
Reports 


Customize a report for incidents at 
a plant or for a particular 
individual. Plant level clinicians 
may view the report created by the 
investigator for an incident. 


Management 
Summary Report 


Further customize the review of 
incident reports. 


Custom Analytical 
Reporting 


Reports generated by Data Analysis 
Module . 
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Task Link 


Description 


Regulatory 
Reports 


Links you to various regulatory 
reports . 


OSHA Log 


The standard Occupational Safety 
and Health Administration log. 
This report does not contain 
deleted cases . 


OSHA Log 
Analysis 


Customize a view of the log 
including deleted cases . 


OSHA Inj/Ill 
Incident 


Customize by injury or illness. 


OSHA Summary 


Used to meet employee posting 
requirements . 


OSHA Extension 


Displays activities for the past 30 
davs excludincr the current date 


OSHA Inj/Ill 
Incident for 
Auth. Empt. 
Rep . 


Reports a list of privacy concern 
cases . 


Privacy Concern 
Case 


Links you to various facility level 
reports . 


Reports By 
Fac i 1 i tv 


Lists all four types of revisits: 
recruired revisits restriction 
revisits, medical leave revisits, 
and immunization revisits. 


Medical 

Revisit Report 


Lists all visits to a treatment 
facility. 


Medical Visits 
by Facility 


Lists all visits to a treatment 
facility . 


MpH i 1 

Restrictions by 
Facility 


Til t~ Pi 1 1 nprcnnc U71 t*Vl r~ p> c; +- >- -1 /-« +~ -j on 
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history in a facility. 


Medical Leaves 
by Facility 


Lists all oersons with leaves in a 
facility . 


Reports For 

Individual 

Person 


Links you to various person level j 
reports . 


Visit Summary Report 
by Individual 


Print reports of medical visits 
with associated revisits. 
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Medical 

Restrictions Report 
by Individual 


restriction history . 


Medical Leave 
Report by 
Individual 


Displays a person's leave 
history . 


RESTRICTIONS/ 
JOB PLACEMENT 


Access open restrictions for a 
person or all persons in a 
facility, department, or work 
location to allow you to 
either job place or open a NWA 
leave . 


VIEW RESTRICTIONS 


View a person's restriction 
history, displaying both open 
and closed/deleted 
restrictions . 


VIEW/UPDATE 
MED I C AL L E AVE S 


Access the leave history, 
create a new leave and edit an 
existing leave depending on 
your role and some business 
rules . See the Medical Leave 
section for more details. 


VIEW MEDICAL LEAVES 


View a person's medical leave 
history, displaying both 
open/prescheduled and 
closed/deleted leaves . 


VIEW/UPDATE USER 
INFORMATION 


Access the EMR User 
Information screen displaying 
your current user information. 
Medical users requiring 
licensor update this 
information through this link. 


WORK OUEUE MED I C AL 


Displays the Work Queue Search 
screen, a quick means of 
accessing action items. 


WORK QUEUE 


Displays the Work Queue Search 
screen, a quick means of 
accessing action items. 


FAQ 


Access a list of frequently 
asked questions . 


GIRS 


Link to the Global Incident 
Reporting Application home page. 
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Help 


Link to the OHSIM online help 
files . 


Ergonomics 


Link to the HCM Healthcare 
Ergonomics website. ; 


Health Care 
Management 


Link to the HCM online website. 



Incident Investigation Module (202) 

The Incident Investigation Module (IIM) is 
an online tool that enables users to capture information 
5 from the investigation of a work-related injury/illness 
incident, a property damage incident, or a near miss. It 
enables users to generate detailed reports of specific 
incidents, specific corrective actions, and provides 
users with the capability to generate a summary report 

10 for all incidents occurring within a specific time frame. 
The information stored within IIM can be used for risk 
analysis and loss control . 

Figure 7 is a block-flow diagram illustrating a 
preferred methodology for using and implementing the IIM. 

15 Notably, the content and arrangement of the diagram 
illustrated in Figure 7 may be adapted to best-fit a 
particular implementation of the present invention. As 
represented in block 34, an incident investigation 
process begins when a person is injured or ill and visits 

20 his or her medical facility or department for treatment. 

As described in greater detail - in accordance with the EMR 
aspect of the OHSIM system, a healthcare representative 
inputs information relating to the medical visit into the 
OHSIM system, as represented by block 36. As a result, a 

25 "Work Queue" record for the incident is automatically 
generated within the OHSIM system, as represented in 
block 38. Work Queue records are accessible and 
searchable through the IIM module. Next, as represented 
in block 40, an authorized/qualified individual (e.g., 
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supervisor) completes an incident investigation, and 
reports his/her findings into the IIM. Preferably, after 
the incident has been investigated, it is reviewed by 
more senior management (block 42) and signed-off on by a 
5 corporate safety representative (block 44) . 

Figure 8 is an example GUI illustrating a Work 
.Queue Search. This GUI provides users with a flexible 
tool for accessing task information relating to an 
incident investigation. Preferably, the Selection 

10 Criteria 46 and Search Results 48 appear on the same 
window for ease of use and viewing. By providing 
"hotlinks" (e.g., 50) to more information about a 
particular record, users may easily and quickly access 
screens or pop-up messages to help complete various 

15 tasks. For example, selecting hotlink 50 will cause a 
medical incident report to display. In addition, the 
user is provided with buttons or selections (not shown) 
to initiate an investigation and/or send a notification 
to an investigator. 

20 Following are some examples of how different 

user roles might use the Work Queue: 

• Supervisors can search for all new incidents 
requiring an investigation in their work location or 
within the plant /building . They can also indicate 

25 whether employees with restrictions can be placed in 

a job . 

• Safety engineers can search for all new 
outstanding investigations within their plant. 

• Superintendents can search for new 

30 injury/illness incidents requiring investigation and 

overdue action items . 

• Area managers can search for overdue action 
items . 
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Medical personnel can view a list of incomplete 
visits, revisits due, unattached leaves, and 
assigned tasks. 

• Human resources representatives can search for 
5 any unplaced employees and edit leaves. 

Worker's compensation representatives can view 
a list of new first time occupational visits 
(FTOVs) or review visits requiring code adjustments. 
Table 11 contains example task descriptions and 
10 roles corresponding to various "Actions" within selection 
criteria 46 . 



TABLE 11 



ACTION 


TASK DESCRIPTION 


ACCESS BY ROLE 


DESCRIPTION 






Complete 
Investigation : 
Filters those 
investigations 
that the user has 
initiated. 


Click the action 
link to open the 
Investigator 
Information screen, 
and complete all 
the required 
screens in the 
investigation . 


Supervisor Safety 
Engineer* 

*Will see all 
investigations 


Review 

Restriction ( s ) : 
Filters reported 
open restrictions 
from medical . 


Click the action 
link to review 
restrictions on the 
Job Placement 
screen. Click 

(Yes) if the person 
can be placed. If 

(No) is selected, 
the record is 
transferred to 
Human Resources to 
determine if a no 
work available 
leave is warranted. 


Supervisor | 



- 48 - 



ACTION 


TASK DESCRIPTION 


ACCESS BY ROLE 


DESCRIPTION 






Sign Off 
Investigation : 
Filters 

investigations 
that have been 
reviewed and 
accepted by the 
superintendent . 
Also filters 
investigations 
completed by 
safety but not 
signed off. 


Click the action 
link to open the 
View Investigation 
screen. Click 
[Sign Off] to 
approve the 
investigation . 
Click [Reject] to 
send it back to the 
investigator to 
update. If the 
investigation is 
re j ected, a reason 
or comments must be 
entered . 


Safety Engineer 


Update 

Investigation : 
Filters reviewed 
investigations 
that a 

superintendent 
and/or safety 
determine need 
modification or 
clarification . 


Click the action 
1 ink to open the 
View Investigation 
screen. The 
Superintendent 
Comments or Reason 
for Rejection will 
display. Update 
the investigation 
as needed. 


Supervisor Safety 
Engineer 


View Incident: 
Filters reported 
injury/ illness 
incidents from 
medical that 
require 
investigation . 


Click the action 
link to open the 
Medical Incident 
Report, detailing 
the Person ' s 
Statement of 
Incident along with 
other medical 
details. Click 
[ Initiate 
Investigation] at 
the bottom of the 
report to start the 
investigation . 

* Superintendent 
does not have 
access to initiate 
investigation . 


Supervisor Safety 
Engineer 
Superintendent * 

*Read-only access 
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ACTION 


TASK DESCRIPTION 


ACCESS BY ROLE 


DESCRIPTION 






Notification : 
Filters overdue 
reported 
injury/ illness 
cases from medical 
that have not been 
completed or 
reviewed . 
Displays yellow 

(2-4 days) or red 

(over 4 days) 

1 eve Is of urgency . 


Click the action 
link to view 
Medical Incident 
Report for 
injury/ illness 
cases and Incident 
Investigation 
Report for all 
others . 


Superintendent 
Area Manager 


Review 

Investigation : 
Filters completed 
investigations 
that require 
approval . 


Click the action 
link to open the 
View Investigation 
screen. Click 

[Accept] to approve 
and send the 
investigation to 
safety for sign 
off. Click 

[Reject] to send it 
back to the 
investigator to 
update . 


Superintendent 


Review 

Notification : 
Filters completed 
investigations 
awaiting review by 
superintendent . 


Click the action 
link to open the 
Incident 
Investigation 
Report . 


Safety Engineer 


Review Anon Near 
Miss: Reserved for 
future 

functionality . 


Not available. 


Safety Engineer 



As mentioned above, the EMR and IIM modules are 
configured to generate a variety of automatic or semi- 
automatic e-mail notifications to assist in the effective 
5 reporting, investigation and resolution of injury/illness 
incidents within the workplace. Within the EMR module, 
health care representatives are able to identify the 
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incident supervisor of an injured or ill employee while 
reporting a medical visit. The OHSIM system may be 
configured to automatically send an e-mail notification 
of the visit to the specified incident supervisor that 
5 includes a link to the incident pending investigation. 

Similarly, e-mail notifications may be 
initiated within the IIM module via the work queue as 
well. For example, if another user finds an incident in 
the Work Queue that should be investigated by someone 

10 else, that user can send e-mail directly to the 
supervisor, reassigning responsibility for the 
investigation. Superintendents and area managers can 
send e-mail to the designated supervisor, while viewing 
the medical incident in the Work Queue. In each 

15 instance, the OHSIM system generates an e-mail 

notifications that include a link to the incident report. 

In one implementation of the present invention, 
there are four types of investigations : 
•Human In jury/ Illness - medical personnel process an 

20 injured or ill person. In jury /illness investigations can 
only be accessed from the Work Queue task link. 
•Near Miss - any incident, which could have resulted in a 
serious occupational injury, illness, or significant 
property damage . 

2 5 •Property Damage - all property damage incidents where the 
loss exceeds $5,000 - $15,000 depending on the specific 
plant, including business interruptions. 
•Risk Assessment - an evaluation of a job task or work 
environment for all potential hazards including, but not 

30 limited to, those causing acute injury or cumulative 
trauma, and other adverse health effects caused by 
exposure to heat, cold, noise, radiation, and toxic 
materials. 
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Notably, a wide-variety of different 
investigation types may be supported by the OHSIM system 
depending upon the particular implementation of the 
present invention. 
5 Figure 9 is a multi-tab GUI for collecting a 

plurality of information relating to a new incident 
investigation. Notably, the content and arrangement of 
the GUI illustrated in Figure 9 may be modified or 
adapted to best fit a particular implementation of the 

10 present invention. 

The investigator information screen illustrated 
in Figure 9 is used to capture information 52 such as a 
plant or building in which the incident occurred, the 
name and contact information for the incident 

15 investigator, the date and time of the incident, the 

investigation type, the investigator's description of the 
incident, and statements made by one or more witnesses to 
the incident. Additionally, the GUI includes header 
information for the incident including the person's name, 

20 identification number, work location, job description, 
and an investigation number for the incident. 

Notably, the features shown and described with 
respect to Figure 9 are all included in one or a 
plurality of screen tabs 54 including investigator 

25 information screen, location/job information screen, 
incident analysis screen, corrective action screen, 
witnesses screen, cost screen, injury/illness information 
screen, complete/verification screen, view investigation 
screen, and attachments screen. 

30 Preferably, if medical personnel have already 

processed an injured or ill person, the human 
injury/illness investigation type is automatically 
selected. Some indicant details may be pre-populated 
with information entered by medical personnel. According 
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to one embodiment, the investigator must initiate 
injury/illness investigations from the Work Queue. 

The location/ job information screen (not shown) 
is used to capture data related to where the incident 
5 occurred and specific data related to the incident. In 
one embodiment, this screen is divided into two sections, 
a location information section, and a job information 
section. If the incident happened in an off -facility 
location, a checkbox may be selected and specific 

10 location information may be entered. If an 

injury/illness incident did not happen at a person's 
normal work location, the displayed fields may change 
accordingly. The job information portion of the screen 
captures specific data related to the job of a person 

15 involved in an injury/illness incident. 

Information collected at the location/job 
information screen may include an indication as to 
whether the incident occurred on or off facility 
premises, an indication as to whether the incident 

20 occurred at the person's normal place of work, 

information describing the location of the incident (e.g. 
plant /building, department, work location, incident 
location/bay, station number, etc.), and employee job 
information (e.g. job code, job description, job 

25 experience, shift, etc.). 

The incidence analysis screen (not shown) may 
be implemented to document the incident in greater 
detail. In one embodiment, the incident analysis screen 
is divided into three sections. The first section 

30 defines the general source of injury. The second section 
assesses the actual and potential risk, using a risk 
factor matrix calculation. The third section defines the 
contributing factors to the incident, such as substandard 
acts and conditions. 



The incident analysis screen may receive 
general incident analysis information including the type 
of contact or the manner in which the employee was 
exposed to the incident or injury, the source of the 
5 injury, and the task/activity the employee was performing 
when the incident /injury occurred. 

A loss severity/probability of reoccurrence 
portion of the incident analysis screen may include 
selection of an actual loss severity/probability of 

10 reoccurrence value as well as a potential loss 
severity/probability of reoccurrence value. A 
contributing factors portion of the incident analysis 
screen may enable a user to define a substandard act, a 
substandard condition, a personal factor, a job factor, 

15 and/or controlling program element that led to or 
otherwise contributed to the incident under 
investigation . 

Table 12 sets forth example loss 
severity/probability of reoccurrence values in accordance 

2 0 with one implementation of the present invention. 



- 54 - 



Table 12 



Severity of 

Likelihood 
of Event 


Non- 

TH c; ^ "HI t t\CI 

Injury/ 
Illness - 
No medical 
treatment 
required 


First 

A i c\ I "R *=rr 

Medical 
Treatment 


In jury /Days 

J-J W O / 1 L.U J- 

Recovery 


Ma j or 

Tnnii r~\7 / 

Less Than 
Full 

Recovery 
(permanent 
impairment) 


Death/ 
Total 

Disability 


1 event/ 
40+ Years 


1 


2 


3 


4 


5 


1 event/ 
4 Years 


2 


4 


6 


8 


18 


1 event/ 
6 Months 


3 


6 


9 


12 


15 


1 event/ 

2 Weeks 


4 


8 


12 


16 


20 


1 event/ 
Day 


5 


10 


15 


20 


25 



A corrective action screen (not shown) may be 
utilized to capture recommended corrective actions to 
5 prevent reoccurrence of an incident. Notably, multiple 
corrective actions may be added for a single incident. 
In addition, a corrective action may be deleted if it no 
longer applies. 

In one implementation, the corrective action 

10 screen receives user input defining, for a new corrective 
action, the type of correction action (e.g. interim, 
permanent) , a description of the recommended corrective 
action, a target completion date for the recommended 
corrective action, and an actual completion date. In 

15 addition, a person responsible for implementing or 
otherwise overseeing the corrective action may be 
identified. 

The witnesses screen (not shown) may be 
utilized to capture information from and about any 

20 witness to the incident. Witness information includes 

the witness's name, identification, contact information, 
and comment. Witness records may be removed from the 
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incident investigation, but preferably the witness record 
is retained . 

A cost screen (not shown) may be used to 
capture known actual and potential costs of the damages 
5 to people, equipment, environment and material, etc. 

Current plant policies and procedures for costing may be 
utilized as guidelines to complete this screen. 
According to one embodiment, an actual and potential cost 
value is input for each cost category (i.e. people, 

10 equipment, environment, material, etc.). People cost 
represents the cost of people involved in the incident 
(i.e. the cost of replacing an injured person with 
someone else, etc.). Equipment cost represents the cost 
of the equipment involved in the incident (i.e. the cost 

15 of repairing or replacing equipment as a result of an 
incident occurring) . Environment cost is the 
environmental cost associated with the incident (i.e. the 
cost to clean up a chemical spill) . 

An injury/illness information screen (not 

20 shown) may be utilized to capture information entered by 
medical personnel for an injured/ill person. Preferably, 
this screen is implemented as a read-only screen and 
cannot be changed by investigators. It is additionally 
preferred that any diagnosis information within a 

25 person's medical record is maintained as confidential and 
does not display on the screen. Preferably, any other 
appropriate information is automatically transferred or 
otherwise transmitted to the incidence investigation 
record from the person's medical record. In one 

30 embodiment, a button is provided allowing an investigator 
to view diagnosis information. Only OSHA-recordable 
events will be displayed. Information displayed may 
include the body part or area affected by the person's 
injury or illness, the side of the body or region where 
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the injury/illness is located, and an injury/illness type 
(e.g. injury, illness, repetitive motion, etc.). Days 
away from work due to this incident may be identified as 
the number of full days unavailable for work due to an 
5 injury or illness. This field may be blank if the 

information has not already been entered into the EMR . 
Preferably, a first time occupational visit number is 
provided as a unique number assigned to new occupational 
visits and may also be blank if the information has not 

10 previously been entered into the EMR (discussed above) . 

A complete/verification screen may be provided 
that is similar to the EMR verification screen shown in 
Figure 4. The complete/verification screen may be 
utilized to determine the status of the documentation for 

15 an incident investigation. In one implementation, a 
checkmark appears in the "required fields completed" 
column next to any screen for which all required fields 
have captured data. The user may return to an incomplete 
screen from the complete/verification screen by clicking 

2 0 on the corresponding screen name hyperlink. Notably, an 
investigation cannot be designated complete until all 
required fields are done. Once all required data fields 
have been completed, a user may select the complete 
button and be presented with a sign off form (not shown) . 

2 5 In one embodiment, once an investigation has been signed- 
off on, no additional editing may take place. 

An attachment screen (not shown) may be 
utilized to attach pertinent information to an 
investigation. The attachment can be any type of file 

30 such as a photograph, spreadsheet, graphic or document. 

Figure 10 illustrates an example view and 
investigation screen in accordance with one aspect of the 
present invention. The view investigation screen 
provides an easy way to review existing information about 
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an incident investigation. A summary of the entire 
investigation may be displayed from the screen, and can 
be viewed before printing a paper copy. According to one 
embodiment, superintendents are transferred to the screen 
5 from the work queue in order to review and accept 
investigations completed by supervisors. Once the 
superintendent accepts an investigation, it is available 
in the work queue for the safety engineer to sign-off on. 
By selecting any of the hyperlinks 56 provided in the 

10 view investigation screen, the user is taken to a summary 
of information inputted into the corresponding screen 
(discussed above) . Additionally, a superintendent may 
input comments 58 or a reason for rejecting the 
investigation and safety comments or reasons for the 

15 rejection. 

Preferably, a restriction information screen 
(not shown) is provided as an aspect of the present 
invention to input selection criteria and view persons 
with active medical restrictions. This information 

20 assists supervisors in assigning employees to jobs that 
accommodate their restrictions. Preferably, the 
restriction information screen is also accessible from 
the work queue (discussed above) . Search criteria may 
include plant /building, department, work location, person 

25 name, and person identification number. By selecting one 
of the search results, a user may be presented with a 
description of that user's restriction ( s ) , in the 
corresponding begin date, through date, and revisit date. 

Additional search functionality may be provided 

30 enabling users to search investigation records. Search 

criteria may include investigation identification number, 
an investigator's identification number, person name, 
investigation type, incident plant /building, incident 
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department, incident work location, and incidents that 
occurred within a user-specified date range. 

An additional search screen enables users to 
search for people involved in or otherwise associated 
5 with incident records. Search criteria for the people 
search may include first name, last name, identification 
number, date of birth, country, plant /building, etc. 

The incident investigation module may be 
programmed and configured to generate a plurality of 
10 reports based on information collected in connection with 
incident investigations . 

Table 13 associates a plurality of IIM-related 
reports with likely users of those reports. Some reports 
are described in greater detail below. 

15 

Table 13 



Report 


Users 


Work Queue Management Report 


Area Managers, Plant Safety, 
Test Track Safety, 

Divisional Safety, Country 

Safety, Corporate Safety, 

Plant Union Rep, Country 

Union Rep, HRA-Safety 


Management Summary Report 


Supervisors , Superintendent , 
Area Manager, HRA-Safety, 
Plant Safety, Test Track 
Safety, Plant Union Rep, 
Divisional Safety, Country 
Safety, Country Union Rep, 
Corporate Safety 


Work Queue Lister Report 


Any user with the Work Queue 
Task ( Supervi sor s , 
Superintendents , Area 
Managers, Plant Safety, Test 
Track Safety) 


Restrictions/ Job Placement 
Report 


Supervisors, Plant Safety, 
Test Track Safety 
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Report 


Users 


Regulatory Reports 


Plant Safety, Test Track 
Safety, HRA-Safety, Plant 
Union Rep 


Reports by Facility 


All Plant Level Users , 
except Plant Union Rep 


Reports by Individual 
( Future Enhancement ) 


All Plant Level Users, 
except Plant Union Rep 


Corrective Action Report 


Supervisors , Superintendent , 
Area Manager, HRA-Safety, 
Plant Safety, Test Track 
Safety, Plant Union Rep, 
Divisional Safety, Country 
Safety, Country Union Rep, 
Corporate Epidemiologist , 
Corporate Safety 


Investigation Report 


Supervisors , Superintendent , 
Area Manager, HRA-Safety, 
Plant Safety, Test Track 
Safety, Plant Union Rep, 
Divisional Safety, Country 
Safety, Country Union Rep, 
Corporate Epidemiologist , 
Corporate Safety 



A corrective action report may be utilized to 
generate a report for information regarding a corrective 
action, particularly an outstanding corrective action. 
5 Primary safety engineers, superintendents, and area 
managers may use such a corrective action report. 
Preferably, a corrective action report search screen is 
provided (not shown) for searching corrective actions by 
a variety of criteria including incident plant /building, 
10 investigation I.D. number, incident department, incident 
work location, corrective action type, and target date 
range. Search results include a listing of corrective 
actions by investigation I.D. number and include a 
description of the corrective action. Preferably, a 
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hyperlink is provided enabling the user to view each 
investigation record . 

An incident investigation report (not shown) 
may be utilized to view and print reports after an 
5 incident investigation has been entered into the system. 
Preferably, a search screen is provided enabling the user 
to search among all incidents according to a plurality of 
search criteria. Search criteria may include incident 
plant /building, investigator identification number, 

10 investigation type, incident department, incident work 
location, person or Witness name, incident date range, 
incident j ob code/description, diagnosis/observation, 
type of contact, source of the injury, and task/activity. 
Additionally, incident reports may be searched according 

15 to loss severity/probability of reoccurrence including an 
actual value, potential value, a substandard act, a 
substandard condition, and a controlling program element 
or detail. Similar to the corrective action report, 
search results for the incident reports are preferably 

2 0 provided with a corresponding hyperlink enabling a user 

to view the relevant investigation record. 

A management summary report screen (not shown) 
may be utilized to generate a report for occupational 
incident activity reported to a medical facility for 
25 treatment that occurred at a user's assigned 

plant /building . Preferably, an investigation link will 
appear for any investigation that has been initiated for 
an incident. If an investigation has not been initiated, 
only the injury/illness incident will display on the 

3 0 report but without corresponding investigation 

information. Near miss, property damage and risk 
assessment incidents may also be associated to an 
investigation and may be viewed through this report. 
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According to another aspect of the present 
invention, a plurality of regulatory reports may be 
automatically generated, including an OSHA log report, an 
OSHA log analysis report, an OSHA summary, and an OSHA 
5 injury/illness incident report for an authorized employee 
representative report. The OSHA log report is the 
official year-to-date occupational safety and health 
administration log. This report may not include deleted 
cases. Preferably, two different layouts are provided: 
10 Form 200 for years 2001 and prior; Form 300 for years 
2 002 and beyond. 

The OSHA log analysis report provides selection 
criteria to customized what is displayed on the OSHA log 
report, including deleted cases. Preferably, two 
15 different layouts are provided: Form 200 for years 2001 
and prior; Form 3 00 for years 2 002 and beyond. 

The OSHA summary report is used to meet 
employee posting requirements in accordance with OSHA 
requirements for the year 2 0 02 and beyond. Preferably, 
-2 0 summary counts for years 2 001 and earlier appear on the 
last page of the OSHA log report. 

The OSHA injury/illness incident report for an 
authorized employee representative is available to 
authorized employee representatives, as defined by OSHA, 
25 for the year 2002 and beyond. This report provides 
information from a medical visit (in particular, 
occupational detail information) for a particular OSHA 
case. Preferably, this report provides only case 
supplementary information regarding a case on the OSHA 
3 0 log, and does not show any information regarding the 

employee and the physician/health care professional. The 
layout for this report may be defined by OSHA Form 301. 

A work queue management report (not shown) 
provides a tool for viewing incident work queue related 
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counts at various stages. Preferably, statuses are 
displayed according to a green yellow and red status 
format for selected incident plants/buildings for 
incidents involving restrictions, incidents not 
5 initiated, incidents not complete, incidents awaiting 
review, incidents awaiting sign-off, and incidents 
awaiting update. The work queue management report is a 
real-time report, displaying information accurate to the 
date and time the report is generated. Totals for the 
10 green, yellow, and red statuses may be displayed by 
plant /building . 

Data Analysis Module (204) 

The data analysis module (DAM) is a custom 

15 analytical reporting aspect of the present invention. 

This aspect of the present invention provides users with 
an ability to compile and process organizational 
information relating to occupational health and safety. 
Basic and detailed reports for incident investigations, 

2 0 property damage, and near-miss incidents can be generated 
based on user selected criteria and include single plant 
or multi-plant reporting. This aspect of the present 
invention may be implemented in a web-based environment 
and may improve efficiency, standardize health and safety 

25 functions, and report/track trends for injury/illness, 
property damage, and near-miss incident types. 

Figure 11 graphically illustrates a methodology 
for utilizing the data analysis module aspect of the 
present invention. Data is filtered at a plurality of 

30 levels, including, but not limited to, worker 

characteristics 60, injury/illness codes 62, work 
assignment 64, time period 66, etc. to arrive at a final 
selected data set 68 for incorporation and/or 
presentation in a plurality of outputs (e.g. visual 
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charts 70, data tables 72, database data exports 74, 
etc . ) . 

Table 14 illustrates a comparison of some high- 
level functionality and distinguishing characteristics 
5 between the DAM module and the IIM/EMR modules. 



Table 14 



IIM/EMR 


DAM 


Driven by single person 
• Data reviews are done 
on a case by case 
basis . 


• Driven by groups or 
population of workers . 
Ability to narrow down 
or focus on clusters of 
workers . 

• Presents trends and 
patterns by counts and 
rates . 

Feeds other Systems : 
PLAID, TIGR, POLR 



Figure 12 is an example GUI having a plurality 
10 of tabs associated with data selection and output in the 
DAM. The basic selections form 78, as illustrated in 
Figure 12, may include functionality for selecting a 
particular plant, or a multi-plant analysis 80, a period 
of observation 82, an incident type 84, and a report type 
15 86 . 

Figure 13 is an example DAM form 88 for 
specifying the format of the data to be output. 
Selection criteria includes the numeric format of the 
output (e.g. discrete counts, rates over time, etc.) 90, 

20 chart type 92, a descriptive primary access and sub-group 
selection 94, a record scope selection 96, a chart 
orientation selection 98, and a custom subtitle 100. 
Description access information may include year, work 
location, visit type, type of contact, time on job, time 

25 into shift, task/activity, sub-standard condition, sub- 
standard act, source of injury type, source of injury 
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detail, etc. Rate selections may include incident per 
2 00,000 hours, persons per 1,000 workers, days away per 
1,000 workers, days away per 2 00,000 workers, restricted 
days per 1,000 workers, restricted days per 2 00,000 
5 hours, days away and restricted days per 1,000 workers, 
days away and restricted days per 200,000 hours, etc. 

The format output form allows a user to modify 
the format of the chart/table or specified listing 
report. Notably, the information displayed on this 

10 screen may differ depending on the report type selected. 
The count values include the number of a specific item, 
such as incidence, days, persons, etc. The rate values 
include the rate at which an action occurred. The chart 
type selection 92 specifies the type of chart to be 

15 generated. Depending on the selection, different fields 
may be displayed or become unavailable. Table 15 
contains example chart types corresponding to the type of 
data those charts might be utilized to display. 

2 0 Table 15 



Chart Type 


Examples Of When Used 


Simple Bar 


Number of incidents by department 


Complex Bar 


Number of incidents by department by 
shift 


Simpl e Time 
Trend 


Number of incidents in a month by 
department 


Complex Time 
Trend 


Number of incidents in a month by 
department by shift 



Figure 14 is an example chart output in 
connection with the DAM aspect of the present invention. 
Notably, current filter criteria 102 is provided enabling 
25 a user to understand the status of the current filter 
selection . 
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A review selection tab (not shown) illustrates 
a summary of user-defined selections (e.g. basic 
selections, detailed selections, output format, etc.). 
Selections presented include the current status of 
5 organizational variables, personal variables, visit type, 
injury/illness variables, body parts, incident 
investigation codes, cost, output format, etc. 

Figure 15 is an example DAM GUI for specifying 
detail selections associated with statistical reporting 

10 in the DAM aspect of the present invention. More 

specifically, Figure 15 illustrates plant selections 
associated with the custom analytical reporting. 
Notably, a variety of hyperlinks 105 may be selected by 
user to present the user with a form for specifying 

15 detail selections for a plurality of DAM-related 

analytical reporting parameters (e.g. plant selection, 
organizational variables, personal variables, visit type, 
injury/illness variables, body part, incident 
investigation codes, cost, etc.). Selections include 

20 company name 104, region/country selection 106, 
region/country selection functionality 108, 

division/subdivision selection 110, division, subdivision 
selection functionality 112, and plant selection 
functionality 114 . 

25 Figure 16 is an example detail selection screen 

for organizational variables in accordance with the DAM 
aspect of the present invention. The organizational 
variable GUI shown in Figure 16 enables a user to filter 
data by job code (e.g. plant-wide or specific job code 

30 selections) 116. Job skills may be generally 

categorized/filtered as skilled or unskilled 118. A job 
code filter 120 is provided enabling a user to search 
among textual descriptions of available job codes. For 
example, a user may search for all job codes associated 
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with welding by inputting the term "weld" into the job 
code filter field 122, depress the "filter" button 120 
and be presented with a plurality of job codes in field 
124 for selection into a selected job code field 126 via 
5 selection functionality 128. Additional selections (not 
shown) may include in-plant groupings, departments, work 
locations, job processes, shifts, etc. 

The personal variables GUI (not shown) enables 
a user to select information about the type of people to 

10 be reported on. The user can select to report on all or 
a specified selection of variables. Variable selections 
may include pay status (e.g. hourly, salary, etc.), 
employee types (e.g. regular, apprentice, agency, 
temporary, etc.), gender, seniority, time on job, age 

15 group, ethnic group, etc. 

A detailed selection form for visit type (not 
shown) enables a user to select the medical case types to 
be reported on. The reports can be based on first time 
occupational visits, first time personal visits, or both. 

20 Selection fields include a first time occupational visit 
selection, a selection of government reportable cases (if 
FTOV is selected, a user can report on all FTOVs with one 
or more days away from work, and/ or one or more 
restricted days at work, due to an occupational injury or 

2 5 an illness) , cases with days away (report on all FTOVs 

with one or more days away from work due to an 
occupational injury or illness) , cases with restricted 
days (report on all FTOVs with one or more restricted 
days at work due to an occupational injury or illness) , 

3 0 and first time personal visits (for a non-occupational 

injury or illness) . 

A detailed selection form for in jury /illness 
variables (not shown) provides the user with 
functionality to select the type of injury or illness to 
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be reported on. One field that may be associated with 
the injury/illness variable screen includes a selection 
between all injury/illness codes or specific codes to be 
defined below. The following fields are filters for 
5 specifying specific injury/illness codes. A summary 
diagnosis/detail diagnosis selection is provided. 
Selecting a summary diagnosis enables a user to select 
from a drop down list of high-leveled diagnosis to report 
on. A detailed diagnosis, on the other hand, is selected 

10 to specify detailed diagnosis by ICD-10 codes, which are 
provided via drop down menu. An injury/illness code 
field allows a user to select one or more injury/illness 
codes to report on (i.e. blood exposure, burn, contusion, 
etc.). An injury/illness type field allows a user to 

15 select one or more injury/illness types to report on 
(i.e. illness, injury, repetitive motion, etc.). A 
chapter field allows a user to specify the detailed ICD- 
10 diagnosis chapter information (i.e. chapter 19 injury, 
poisoning and certain other consequences of external 

20 causes) . A main category selection field enables a user 
to categorize/define the area associated with an 
injury/illness via ICD-10 code (i.e. 19-15327 -injuries to 
the ankle and foot) . Sub-category selection fields are 
also provided to describe or further define the injury 

25 (i.e. 19-15327-S91 . 0 open wound to ankle). 

A body part detail selection form (not shown) 
enables a user to select body parts to be reported on. 
Users can select from all body parts or from specific 
body part selections. Body part selections may be made 

30 via body part group, body part, laterality, etc. 

An incident investigation code detail selection 
GUI (not shown) enables a user to select from all or 
specific incident details to report on. One selection 
field includes the type of contact. For example, contact 
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with a source of energy or substance. Another selection 
field includes the source of "the injury. For example, if 
the type of contact was slip, trip, or fall, then the 
source of the injury value could be working surface. A 
5 task/activity field enables a user to specify what task 
or activity the person was doing when the incident 
occurred (i.e. maintenance or repair, emergency, material 
handling, etc.). A sub-standard act field allows a user 
to specify a result of a sub-standard condition that was 

10 allowed to exist in an individual resulting in a sub- 
standard act/behavior (i.e. failure to use personal 
protection equipment, removing safety devices, etc.). A 
sub-standard condition selection field specifies a 
condition that was allowed to exist in the work place 

15 that led up to the incident (i.e. congested or restricted 
action/area, inadequate ventilation, inadequate guards, 
etc.) . A controlling program element field specifies the 
type of safety program that most directly applied to an 
incident under investigation (i.e. chemical safety, no 

20 program or standard, etc.). A loss severity /probability 
of reoccurrence field may reflect actual or potential 
values. A graph icon is provided to open a window 
allowing a user to select the actual loss of severity and 
the probability of reoccurrence. A vertical access 

2 5 presented within the window may represent the actual 

frequence or likelihood of the event occurring. A 
horizontal access may represent the actual severity of 
the event. (See Table 12 for an example loss 
severity/probability of reoccurring stable.) Preferably, 

3 0 color descriptions are provided for frequency. Green 

(low) may be tolerated but should be reduced if possible 
with minimal investment. Yellow (medium) should be 
modified unless unreasonable. Red (high) is not 
tolerated, and correction is mandatory. For 
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injury/illness incidence, the color scheme can be 
interpreted based on severity logic as follows: green 
means no medical assistance was required, yellow means 
medical attention was required with complete recovery, 
5 red means the person was seriously injured and there is 
permanent impairment, or there was loss of life. 

A cost screen GUI for making detail selections 
(not shown) may include a variety of price of cost 
related criteria to be reported on. For example, reports 

10 may include total actual and potential costs, actual cost 
only, and potential cost only. Cost ranges may be 
specified for the report in a variety of categories (e.g. 
total costs, people costs, equipment costs, environment 
costs, etc.). People costs include the cost of people 

15 involved in the incident (i.e. cost of replacing injured 
person with someone else, etc.). Equipment costs include 
the cost of the equipment involved in the incident (i.e. 
the cost of repairing or replacing equipment as the 
result of an incident occurring) . Environmental costs 

20 include the costs associated with an incident (i.e. the 
cost to clean up a chemical spill, etc.). 

Notably, the DAM aspect of the present 
invention is directly interfaced with the OHSIM suite 
(EMR, IIM, DAM) . According to one embodiment of the 

25 present invention, some data fields are required, whereas 
other fields are dependent on the incident type. For 
instance, type, of contact is required for injury/illness 
incident types, but it may not be a required field for 
near miss or property damage incidents. Table 16 

3 0 summaries which fields which, according to one embodiment 
of the present invention, may be required in OHSIM for 
use in connection with DAM reporting on human 
injury/illness. Of course, fields may be required or not 
depending on the particular implementation. 



Table 16 



Investigator Information 


Responsible Plant /Building 
Incident Date 
Incident Time 

Incident Person Start Time 
Investigation Initiated Date 
Investigation Type 
Investigator Description of 
Incident 

Person Statement of Incident 


Location/ Job Information 


Did the Incident occur at the 

PoyQnn 1 l\7oT~TTi;=i 1 W t~ V - T.nrs 1 — i on*? 

Xz " _L bUll O -LNJ W J- Hid -L Vv Ul. JV 1—1 v— d L. -L Ull . 

Incident Plant /Building 
Incident Job Code/Set ID/ 
Description 
Incident Process # 
Experience in Incident Job 
Incident Shift 


inciaeriL Andiysis 


TK r~r~\ a *F f 1 An ^ ^ "H 
l_y|Jc (J JL V_ vJIl LdL. L. 

Source of Injury/Detail 
Task /Activity 
Substandard Act 
Substandard Condition 
Controlling Program Element/ 
Detail 


Corrective Action 


Corrective Action Type 
Recommended Corrective Action 
Target Completion Date 
Responsible Person - CDS ID 
Responsible Person - Last Name 
Responsible Person - First Name 


Witnesses - Screen not 
required 


Last Name 
First Name 
Relationship 
Witness Comment 


Cost - Screen not 
required 


People 
Equipment 
Environment 
Material 


Attachments - Screen not 
required 


Source File 

Attachment Description 



Table 17 summarizes OHSIM fields which may be 
required for DAM near-miss reporting: 
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Table 17 



liivco i — Ly a lui iiiiui 11 id. Liun 


RpQnnn c i "hi p Pl^Tii"/ Ri i i 1 Hi nrr 

Incident Date 
Incident Time 

Investigation Initiated Date 
Investigation Type 
Investigator Description of 
Incident 


Location/ Job Information 


Incident Plant /Building 
Incident Shift 


Incident Analysis 


Task /Activity 
Substandard Act 
Substandard Condition 
Controlling Program Element/ 
Detail 


Corrective Action 


Corrective Action Type 
Recommended Corrective Action 
Target Completion Date 
Responsible Person - CDS ID 
Responsible Person - Last Name 
Responsible Person - First Name 


Witnesses - Screen not 
required 


Last Name 
First Name 
Relationship 
Witness Comment 


Cost - Screen not 
required 


People 
Equipment 
Environment 
Material 


Attachment ( s ) - Screen 
not required 


Source File 

Attachment Description 



Table 18, below, summarizes OHSIM fields which 
may be required for. DAM property damage reporting: 
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Table 18 



lnvesLiyaLor lnioriuaLion 


KesponsiDie riariL / Duiiamy 
Incident Date 
Incident Time 

Investigation Initiated Date 
Investigation Type 
Investigator Description of 
Incident 


Location/ Job Information 


Incident Plant /Building 


Incident Analysis 


Substandard Act 
Substandard Condition 
Controlling Program Element/ 
Detail 


Corrective Action 


Corrective Action Type 
Recommended Corrective Action 
Target Completion Date 
Responsible Person - CDS ID 
Responsible Person- Last Name 
Responsible Person- First Name 


Cost - Screen not 
required 


People 
Equipment 
Environment 
Material 


Witnesses - Screen not 
required 


Last Name 
First Name 
Relationship 
Witness Comment 


Attachments - Screen not 
required 


Source File 

Attachment Description 



While the best mode for carrying out the 
invention has been described in detail, those familiar 
with the art to which this invention relates will 
recognize various alternative designs and embodiments for 
practicing the invention as defined by the following 
claims . 



